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The study of variability in software development has become increasingly important in recent years. 
A common mechanism to represent the variability in a product line is by means of feature models. 
However, the relationship between these models and UML design models is not straightforward. 
UML statecharts are extended introducing variability in their main components, so that the behavior 
of product lines can be specified. The contribution of this work is the proposal of a rule-based ap- 
proach that defines a transformation strategy from extended statecharts to concrete UML statecharts. 
This is accomplished via the use of feature models, in order to describe the common and variant com- 
ponents, in such a way that, starting from different feature configurations and applying the rule-based 
method, concrete state machines corresponding to different products of a line can be obtained. 

1 Introduction 

A product line (PL), also called system family, is a set of software systems sharing a common, managed 
set of features that satisfy the specific needs of a particular market segment or mission and that are 
developed from a common set of core assets in a prescribed way Q]|2l[3l. 

To develop a system family as opposed to developing a set of isolated systems has important advan- 
tages. One of these is the possibility of building a kernel that includes common features, from which 
desired products can be easily built as extensions. By adding distinguishing characteristics (variability) 
to such a kernel, different products can be obtained |3l 01 IH 13 |H. For example, today we observe 
in the market a significant number of different types of mobile phones (MPs) that share a core of basic 
features and differ in other more specific characteristics: availability of a digital camera, internet access, 
mp3 player, among others. 

The UML language [9] provides a graphical notation and has become the standard for modeling 
different aspects of software systems. Statecharts and interaction diagrams are part of the set of tools 
that UML provide so that the system behavior can be specified, which are specially suitable for the 
software design phase. Statecharts are used to specify the behavior of the instances of a class (intra- 
component behaviour), and therefore constitute an appropriate mechanism for describing the behavior of 
certain problems by means of a graphical representation. In the latest version of UML 2.0, the statecharts 
do not offer operators and/or sublanguages for specifying system families. 

In this paper we propose an extension of UML statecharts for modeling PLs. We used feature models 
so that both common and variant functionality of a system family can be described |[T0l [8), and we 
incorporate variability in the essential components of the statecharts, in such a way that, starting from 
different configurations of a feature model, concrete statecharts corresponding to different products of 
a PL can be generated applying a rule-based method. The approach defines the transformation strategy 
from extended statecharts to concrete UML statecharts. 

The rest of the work is organized as follows. In section 2 and 3 we briefly introduce statecharts and 
feature models, respectively. Section 4 presents an extension of statecharts with variant elements, which 
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together with the use of feature models allow specifying PLs. In section 5 we detail the mechanisms 
for obtaining products of a PL from distinct configurations of a feature model, via the use of rules and 
a transformation strategy. Related work is discussed in section 6 and finally, we conclude and discuss 
possible further work in section 7. We exemplify the proposed work by developing part of a case study 
based on mobile phone technology. A preliminary version of this work is ifTTTl . As opposed to [11], this 
paper presents a rule-based approach. We define an application strategy for the rules in a proper manner, 
in such a way that inconsistencies are avoided in the statechart obtained. The rules are organized in a 
sequence of rule sets, in which each rule set can be considered as a layer. Within a rule set, the rules may 
be applied in a non-deterministic order lfT2l . We also formalized and added rules that in iPTTTl are omitted 
or only described informally. 

2 Statecharts 

UML StateCharts (SCs) constitute a well-known specification language for modeling the dynamic system 
behavior. SCs were introduced by D. Harel IPT31 and later incorporated in different versions of the UML 
with some variations. In this section, we present definitions of SCs based on H4l . For additional details, 
the reader is referred to ifTTl IX4ll . 

SCs consist essentially of states and transitions between states. The main feature of SCs is that states 
can be refined, defining in this way a state hierarchy. A state decomposition can be sequential or parallel. 
In the first case, a state is decomposed into an automata (Or-state). The second case is supported by a 
complex statechart composed of several active sub-statecharts (And-state), running simultaneously. 

Let S, 77?, II and A (IT C A) be countable sets of state names, transition names, events and actions of a 
SC, respectively. Also, let us define s G 5 as either a basic term of the form s = [n] (Simple-state), as a term 
Or of the form s = [n,(s\,...,Sk),l,T] (Or-state), or as a term And of the form s = [n, (s\, s^)] (And- 
state), where name(s) =def n is the name of the state s. Here (s\,...,Sk) are the subterms (substates) of s, 
also denoted by sub_est(s) =def ( J l> Likewise, inicial{s) =def s \ is the initial state of s, T C TR is 

the set of internal transitions of s, and / the active state index of s. A transition is represented as a tuple t = 
(t',s ,e, c, a,Sd,ht), where name(t) =def t' is the transition name, source{t) =def $o and target (?) =def $d 
are called source and target of t, respectively, ev(t) =def e the trigger event, cond(t) =def c the trigger 
condition, and acc{t) =def M is the sequence of actions that are carried out when a transition is triggered. 
In addition, hist(t) =def ht is the history type of the target state of t lTT4ll . The graphical notation used in 
the transitions is t : e,c/tt. 

3 Feature Models 

Feature Models (FMs) are used to describe properties or functionalities of a domain. A functionality 
is a distinctive characteristic of a product or object, and depending of the context it may refer to, it is 
a requirement or component inside an architecture, and even code pieces, among others. FMs allow 
us to describe both commonalities and differences of all products of a PL and to establish relationships 
between common and variant features of the line. There are multiple notations for describing FMs. In 
this work we will use the proposal of Czarnecki iflOl . 

A tree structure instance is a FM configuration ( FMConf) that describes the model and that respects 
the semantics of their relations. That is, a FM allows one to identify common and variant features 
between products of a PL, while a FM configuration characterizes the functionalities of a specific product. 
Formally, the concepts of FMs are defined as follows: 



46 



Specification of Products and Product Lines 



Definition 1. A FM is defined as a tree structure represented by a tuple (Funcs , fo,Mand, Opt, Alt, 
Or-rel), where Funcs is a set of functionalities of a domain (nodes of the tree), fo G Funcs is the root 
functionality of the tree and, Mand,Opt ,Alt ,Or-rel C Funcs x (y(Funcs) — {0}) the mandatory, op- 
tional, alternative and disjunct relations of the model, respectively. If (f,sf)G MandU Opt, #sf = 1. 

Definition 2. A FM configuration corresponding to a FM (Funcs, fo, Mand, Opt, Alt, Or-rel) is a 
tree (F, R) where F is the set of nodes and R the set of edges; F C Funcs and R C {(f,sf)G F x(y(F)— {0}) 
| 3 sf ' G y(Funcs): sf C sf A (f.sf) G Mand U Opt U Alt U Or-rel} . Moreover, the following conditions 
must be fulfilled by (F, R): (1) fo G F; (2) for every (f,sf) G Mand: if / G F then (f,sf) G /?; (3) if (f,sf) 
£Alt Af£F then 3! sf'G 7(F): sf'Csf A (f,sf) G R A #sf'=l; (4) if (f, sf) G Or-re/ A / G F then 3! 
sf'G 7(F): sf'Csf A (f,sf) G/?A#sf>l. 

Definition 3. The kernel Nofa. FM (Funcs, fo, Mand, Opt, Alt, Or-rel) is the set of functionalities, 
which are present in all configurations, inductively characterized by the following rules: (I) fo G A 7 "; (2) 
if fx G N A (/l , {fl}) G Mand then f 2 G tf. 

4 SCs with Variabilities 

In this section we extend the SCs with optional (variant) elements and later on we establish the binding 
between these elements with functionalities of a FM, in order to model the behavior of a PL. We will call 
our proposed extended machines StateCharts* (SCs*). 

4.1 Graphical Representation of a SC* 

The representation of the optional elements that extend the system kernel in a SC* are depicted in figure[T] 
We use dashed lines to graphically denote both optional states as well as transitions. 

' A ] t : b,c / <p> 

Optional State Optional Transition 

Figure 1 : Optional state and Optional transition. 

4.2 Abstract Syntax of a SC* 

Let S*, 77?*, IT and A* be set of states, transitions, events and actions of a SC*, respectively. Now 
the terms that define a state have an additional component S op G {optional, no. optional} that we will 
call StateType(s), which indicates whether the state s is optional or not. Similarly, we add component 
top G {optional, no. optional} to the transitions, and we denote it by TransType(t). We also define the 
following sets of SCs* optional elements: SOp C S*, TOp C TR* and VarElem = SOp U TO p. 

We will refer to states directly by their names, when these are unique for every state in all the SC*; 
otherwise, we will use the dot (.) as separator between state and substate names. A transition name is 
built by the trigger event name followed by source and target state names, respectively. 

4.3 Case study: MPs 

We considered here a family of MPs which share some functionalities, such as, for example, the capacity 
of reproducing monophonic sounds and vibration. Optionally, we could incorporate into the kernel of 
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functionalities the capacity to make calls by means of quick-marked, to write text messages, to adminis- 
ter multimedia contents, and combinations of these, such as messages with multimedia content (images, 
polyphonic sounds and videos). In order to exhibit an example in the development of this article, we 
formulate in figure [3] a FM, using the notation proposed by Czarnecki, that relates the involved function- 
alities in the partially described MP of figure [2] 

4.4 Relation between FMs and SCs* 

FMs and SCs* are complementary. Both model different aspects of a system and in our proposal, will 
not be treated independently, since SC* elements model behaviors of present functionalities in the FM. 
In general, a functionality is described by more than one SC* element. Due to this, we define a function 
Imp, which represents the association between the SC* variant elements and the functionalities of the 
FM. This way we establish what variant elements of the SC* implement the characteristics of the system 
described in the FM. Given a FM (Funcs, f , Mand, Opt, Alt, Or-rel) and a SC* (S*, TR*, IP and 
A*), the type of function Imp is as follows: Imp : Funcs — > SetiVarElem), where VarElem is the set 
SOp U TOp, SOp C S* and TOp C TR*. 

Taking into account that the mandatory functionalities are always present in all products of the line, 
it is not necessary to define the SC* syntactic elements that these implement. However, it is necessary to 
do it for those functionalities that cannot belong to FM configuration. Imp will be then a partial function 
defined on FM elements which do not belong to the kernel. Therefore, the behavior of a PL is defined by 
a FM, a SC*, and a function of implementation that binds them. 

Example 1. Taking the FM of figure[3]and the SC* of case study of figure|2j we define SC* elements 
that implements functionalities of MP as follows: 

7m/j(Polyphonic Sounds) = {SelectPolSound, TRightMultimediaType-SelectPolSound, ToChoosePol 
Sound, TRightSoundType , ToChoosePolSound, TLef tToChoosePolSound-SoundType , TRightToChoo 
sePolSound-PhoneFuncionality , ...}; 7ra/?(Multimedia) = {Multimedia, AdmMultimedia, TRight 
Multimedia. Selecct-SelectContact} U /ra/?(Images) U 7ra/?(Polyphonic Sounds) U 7m/?(Videos); 
/mp(MessagesAdm) = {MessagesCenter , TMessage-MainDisplay-IncomingMess , TMessage-MainDis 
play-MessagesCenter , TLef t-MessagesCenter-MainDisplay , TRight-OptionsMenu-MessagesCen 
ter} U Alarm New Messages); Alarm New Messages) = {MessagesState , TMessageMainDis 

play-IncomingMess}. 



5 Instantiation of StateCharts with Variabilities 

A FM configuration defines a product given a set of selected characteristics. Given a FM configuration 
and the SC* corresponding to the FM (linked via a function Imp), we define an instantiation function that 
returns a SC, which specifies the defined product behavior, Inst : SC* x FMConf — > SC. 

We eliminate of the SC* both states and transitions which implement functionalities not present in 
FM configuration, via the use of the function Imp defined in the previous section. The direct elimination 
of states as well as transitions of the SC* is not trivial. The suppression of SC* components without es- 
tablishing a control can return inconsistent results, such as, for example, unreachable states or transitions 
without target. A control and rebuild mechanism of SCs starting from a SC* is defined in such a way that 
a concrete product is obtained. 



In section 5.1 we present the cases and rules of rebuilding that constitute the base of the instantiation 



method which we included in section 5.2 Later, in section 5.3 we analyze our case study: MPs 
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5.1 Cases and Rebuilding Rules 

Case 1 . When a state is deleted 

Case 1.1. When a simple state is deleted 

If a simple state s = [E] is deleted, then their entry and exit optional transitions are deleted, while the 
mandatory transitions are composed using the following rebuilding method. 

Let E G SOp be the state to eliminate, A\, A„ predecessor states of E (i.e., states from which there 
are non-optional transitions with target E: Iae_\ , tAE_n), and Si, S m successor states of E (i.e., target 
states of non-optional transitions with source E: t£SA, tES-m)- When the variant state E is deleted, all 
entry and exit transitions linked to E are deleted. Simultaneously, new transitions are generated by the 
composition of the non-optional entry transitions (?a£_i, ?A£_«) with the non-optional exit transitions 

( f £S_l, ?£S_m)- 




Figure 4: Resulting SC* after the deletion of the optional state. 

The composition of two transitions t\ = (t\, so\, e\,c\, CC\, sd\, ht\, no-optional) and t% = (?2, S02 , 
£2, C2, OC2, sd2, ht2, no .optional) define a new transition as follows: comp(tl, ?2) = so\, e\ :: e2, 
ci AC2, CCi :: ct2> hh, no-optional), where :: is the sequential composition of events and actions, and 
A the conjunction of conditions. Both operations must be associative in order to make the instantiation 
method deterministic. 

Let sc = (5*, 77?*, IP, A*) be SC* (in future, we will omit the components IT y A*), we define the 
set of entry and exit non-optional transitions pairs of a state E of sc as follows: 

T e ^(E) = {(t e ,t s ) £ TR* x TR*\target(t e )=EAsource(t s )=EATransType(t e ) = TransType(t s ) = 
nojoptional}. 

The result of eliminating an optional Simple-state E of sc corresponds to the following SC* : 
Delete. simple. state(E, (S*,TR*)) = (S* - {E}, TR* U {comp(t e , t s ) \ (t e ,t s ) £ T e _ s {E)} -{t£TR*\t£ 
Domain(T e s {E)) V t £ Range(Te^s(E))} — {t G 77?* | TransType(t) = optional A (source(t) = E V 
target(t) = E)}) We call this rule Delete .simple stateiE , (S*, TR*)). Figure |4] shows the result of their 
application. 

Case 1.2. When a Or-state is deleted 

If an Or-state s = [E, (s\, s^), I, T] is deleted, then their entry and exit optional transitions are 
deleted, while the mandatory transitions are composed using the following rebuilding method. 

The proposal consists of applying the previous transition composition method of case 1.1 on E, 
considering certain conditions and affectations to SC*. Let sc = (S*, TR*) be a SC*, we previously 
define the set of all the entry and exit non-optional transition pairs of an Or-state E of sc* as follows: 
T e _s{E) = {(t e ,t s ) G TR* x TR*\target(t e ) G sub_states{E) A source(t s ) G subjstates{E) A TransType{t e ) 
= TransType(t s ) = no.optional} 

We establish that each entry transition to E is composed with one exit transition if the source state of 
the exit transition is reached from the target state of the entry transition. We define Reachable( E, A ) as 
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the set of reachable substates of E from the substate A. Formally, we define TComp e ^{E) = {(t e ,t s ) G 
Tes{E)\ source{t s ) G Reachable(E , target (t e ))} as the set of transition pairs that must be composed by 
means of case 1.1, previous modification of these transitions as is indicated as follows. For each entry 
transition t e G Domain(TComp e s (E)) its target state is now E, i.e., target(t e ) = E. Also, for each exit 
transition t s G Range(TComp es {E)), source(t s ) = E. The result of eliminating the optional Or-state E 
of sc* corresponds to the SC* following: 

Delete_Or_state(E, (S*, TR*)) = (S* - ({E}(Jsub_states(E)), TR* U {comp(changeJarget(t e ,E), 
change source{t Sj E))\ (t e ,t s ) G TComp e _ s (E)} — {t G TR*\source{t) G ({£} Usubstates(E)) y target {t) 
G ({E}Usub_states(E))}) 

change Jarget(t,E) change the target of transition t, such that target(t)=E. Likewise, change source(t, 
E) change the source of transition t, such that source(t)=E. We call this rule Delete Or _state(E, (S*, 
TR*)). 

Case 1.3. When an And-state is deleted 

If an optional And-state E is deleted, then their entry and exit optional transitions are deleted, while 
the mandatory transitions are composed using a similar rebuilding method to case 1.2. 

Two possible relations of dependency or synchronization between parallel states exist. One of them 
refers to the occurrence of an event that produces the trigger of two or more transitions belonging to each 
one of the parallel substates. The second relation corresponds to using conditions of type 'in £" (see case 
2.2). The latter forces to redefine the concept of reachability, since it is not valid to apply the previous 
definition of reachability in a way independent in each one of the orthogonal states. 

Let E be an And-state with n orthogonal states. We define now Reachable(E,(Ei,E2,...,E n )) as 
the set of n-tuples of reachable states from (E\, E2, ...,E n ). In this way, maintaining the definition of 
T e ^(E) of the previous case and redefining TComp es (E), it is possible to solve the method of transition 
elimination and composition (Delete And state) in an analogous form to case 1.2. 

TComp e _ s (E) = {(t e ,t s ) G T e _s(E)\(3 n-tuplaJnit ,n-tuple_end G (S* x S* x ... x S*)„\ n-tupla_end G 
Reachable(E , n-tuplaJnit) A (3/, j\ < i,j < n\n-tupla-end[i] = source(t s ) An-tuplaJnit[j] = target (t e ) A 
cond(t s )))}, being n the amount of orthogonal states. We call to this rule Delete And state (E, (S*, TR*)). 

Case 2. Consequences of the elimination of a state 

Some situations can appear as a consequence of applying the cases described previously, which must 
be considered in order to reestablish the SC. These situations are analyzed in the following cases. 
Case 2.1. When an initial state is deleted 

If an initial state of a state E = [s, (si, st), I, T] is eliminated, then anyone of their successors 
that belongs to E becomes the new initial substate, i.e. if 3t,t = (t name , s\, e, c, a, s new jnitiali nt ) £ 
T\s new jnuiai G (s 2 , Sk) then initial' (E) =s new j n ukd- We call this rule Delete Jnitialstate(E, (S*, TR*)). 

Case 2.2. When some substate in a parallel decomposition is deleted 

The conditions of transitions in a parallel decomposition of type 'in £" are deleted when the state 
E is eliminated via some FM configuration, i.e. if E is deleted and t = (t name , s , e, c, a, sj, ht) G 
TR\ 'inE'E c, then t' = (t na me, s , e, delete-expresionJn_condition('inE\c), a, sj, ht), where the func- 
tion delete jexpresion An _condition(expr, c) eliminates the logic subexpression of c. We call this rule 
Delete _condition(E, (S*, TR*)). 

Case 3. When a transition is deleted 

If a transition t of a SC* disappears, it does not produce alterations in the SC*.We call this rule 
Delete Jransition(t, (S*, TR*)). 
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Case 4. Changing the optional elements to non_optional elements 

This rule will be used in the reduction strategy, in order to make part of the final product all optional 
elements remainders. That is to say, Vs G SOp* ,StateType(s') = non_optional. In a same way, V? G 
TR* ,TransType(t') = non_optional. We call this rule Changing ^optional Jo Jion_optional(S* , TR*). 

5.2 Instantiation Method 

Given a FM and its configuration, we will call NSF the set of non-selected functionalities of the model 
as consequence of the configuration. Formally, for the FM fim = (Funcs, /q, Mand, Opt, Alt, Or-rel) 
and a configuration conff m = (F, R) of fin, NSF = Funcs — F. We define also the set of non-selected 
components(NSC) by the configuration conff m of SC* sc, which will not be part of the resulting SC, as 
follows: NSC(conf fm , sc) = {x£ VarElem\3fi G NSF : x G Imp(fj) A ->3f { G F : /? Ax G Imp{f[)}, 
with VarElem e Imp defined for sc according to section 4.4. This is, the states and transitions that do 
not implement selected functionalities by a configuration will be excluded, through the rules, from the 
behavior of resulting SC. 

5.2.1 Application Strategy 

The rules should be executed in a certain order for the result to be deterministic. We will assume that 
rules are organized in rule sets, which are then organized in a sequence of rule sets in which each rule 
set can be considered as a layer [12J. Within a rule set, rules maybe applied in a non-deterministic order. 
Syntactically we express layers of rule sets as shown in the following example: given three rules pi, p2, 
and p3, ({pl,p2},p3 |) specifies two layers. The first one contains pi, p2, and the second contains p3. 
This means that first any rule in the first layer is applied, and then the one in the second layer is applied. 
The symbol p J. denotes that the rule p J, is iterated until it cannot be applied anymore. 

The order of application of the rules will determine the order of selection of the elements in NSC 
(conff m , sc). Let sc G SC* , fmc G FMConf, and E,t G NSC(fmc, sc). We establish the following 
application order of rules: 

Sr = ({Delete Initial _state(E , sc), Delete jcondition(E , sc)} J,; 
{Delete simple st at e(E, sc), Delete _Or _state(E , sc), Delete _And_state(E , sc)} \,; 
Delete Jransition(t , sc) J.; Changing ^optional Jo jnon_optional(sc)) 

The strategy should be applied only once. It is important to consider that the application of a rule 
produces the elimination of elements in NSC(fmc, sc). The strategy is completed when NSC(fmc, sc) = 
0. Note that the implementation of the first two rules does not eliminate states, but only change initial 
states and deleting conditions like 'in E'. Later the affected states will be eliminated by the successor 
rules. The rule Changing .optional Jo _non_optional(sc) convert optional elements, which remain in sc, 
to non_optional elements. 

5.2.2 Termination and Deterministic Implementation 

Termination and confluence problems can occur whenever a rule-based approach is used. As termination 
and confluence are fundamental for the correctness of a model transformation, systematically validating 
these properties is a main prerequisite for successful practical applications, such as transformations in 
the MDA context, for example. 

In our context, the property of termination is clear, given that rules are applied on elements of 
NSQfmc, sc), and these are eliminated in each application until NSC(fmc, sc) = . Therefore the 
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strategy is terminating because the rules decrease components of the statecharts (either states or transi- 
tions). 

In general, confluence means that, when there is a choice of applying different rules, the choice does 
not affect the result. The role of the first two rules is to avoid ill-formed statecharts. The main rule is 
Delete simple state(E, sc), since Delete JDr state(E, sc) and Delete _And_state(E, sc) are based on this. 
Note that Delete simple siateiE ,sc) does not produce ill-formed statecharts (see case 1.1). 

The application of a rule r on a SC* is denoted by sc* A- sc* +l , and sc* n -^ 2 sc* i+2 denotes the 
application of r\ y in that order. 

Lemma 1. (Applying two rules.) Letr\, r2 G {Deletesimplestate{E , sc), Delete -Or state(E , sc), Delete 
_Andstate{E , sc)} be two rules to be applied to states El and E2 G NSC(fmc, sc), respectively. 

sc* — > SC*j A sc* ->■ SC* => SC*j = sc*. 

Proof. Let E\ and E% S NSC(fmc, sc) be the states to eliminate. We consider both independent if there 
is no transition which connects, in this case it is clear that the elimination in any order produces the 
same SC. The opposite case is discussed. Let t El = (t El , so\, a\, c\, (X\,E\, ht\, nonjjptional), t^_E 2 = 
( f £!_E 2 5 ^l) a i2> c i2 ; G5i2, E\2, ht 12, non_optional) and ?£ 2 = {t^E^, 02, c%, 0C2, sc^, ^ f 2> non_optional) be 
entry and exit transitions of £1 and £2- On the one hand, we assume that the rule Delete simple state[E\ , 
sc) is applied before rule Delete simple _state(E2, sc), i.e. tE x is composed with t Ex ^ 2 and after compose 
with tE 2 ■ 

comp(comp(t El ,t ElJ ; 2 ),t E2 ) = t El _ {El _ E2) _ E2 = (t El _ iEl _ E2) _ E2 ,soi, {a x wan) »«2, (ciAci 2 )Ac 2 , (dfi :: 
(X12) OL2, sd2, ht2, non_optional). 

On the other hand, if we assume now the inverse application of both rules, we can see that the 
resulting composition has the same result as the previous case. Given that the operators A and :: are 
associative: comp(comp(t El , t El _E z ), t El ) = comp{t E{ , comp{t E{ _ El , t El )). 

The rules Delete Or state and Delete JKnd state are based on the rule Delete simple state , therefore 
we may consider E\ and £2 (see above) as compound states. □ 

Let SC*, R y Sr be a rule-based rewriting system on Statecharts (RS-SC), where R is the set of rules 
defined in section [5~Tj and Sr the implementation strategy on the rules of R. Let ValSeq_SR be the set of 
all valid sequences of applications. 

An RS-SC execution starting from a SC* (sc*) is a sequence s of rule applications of R such that 
s G ValSeqSR. We denote it by sc* — > sc, where sc G SC is a concrete statechart. 

Theorem 1. ( Confluence.) Two distinct executions of RS-SC generate the same statechart. 

sc* -V sc A sc* ^ sc' => sc = sc'. 

Proof. The proof is given by the following: 

Both executions, si and S2, have the same length, since the number of applications of rules is equal to 
#NSC. Moreover, the set of rules of sequence si is equal to set of sequence S2, therefore s\ is a permu- 
tation of S2- Since the rules Delete Jnitialstate, Delete -condition and Changing ^optional Jo Jionjop- 
tional of Sr are clearly deterministic and do not remove states or transitions, we focus only on the 
subsequences of si (subs\) and ^2 (subs2) which include rules Delete simple state, Delete -Or state 
and Delete .And state. 

Since subs2 is a permutation of subs\, the proof follows immediately from Lemma 1 by swap rules 
in any of sequences. □ 
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5.3 Instantiation of the Case study: MPs 

The FM of figure[3]can be configured to characterize different MPs, according to the specification of the 
case study of section [43] Next, we present a configuration of a MP of figure [2] and we proceed towards 
obtaining the corresponding SC (the MP wanted), according to the application order of rules defined in 
section [5721 

A MP with neither the support for the management of polyphonic sounds nor the capacity of alerting 
the user when new messages enter in the incoming mailbox, is defined by the configuration conf/ m = 
(F, R) of the FM of figure [3} where: 

F = {MP, Display, Contacts, MessagesAdm, Multimedia, Images, Videos, Quick-Marking, Ringer _in_func 
tions}, and 

R = {(MP, {Multimedia}), (MP, {MessagesAdm}), (MP, {Quick-Marking}), (MP, {Display}), (MP, {Con 
tacts}), (MP, {Ringer Jn_ functions}), (Multimedia, {Images}), (Multimedia, {Videos})}. 



Taking the previous configuration and the function Imp described in example 1 of section 4.4 the 
sets NSF and NSC(conf/ m , sc) are defined as follows: 
NSF = {PolyphonicSounds,AlarmNewMessages}, and 

NSC(conff m , sc) = {SelectPolSound, TRightMultimediaType-SelectPolSound, ToChoosePolSou 
nd, TRightSoundType-ToChoosePolSound, TLef tToChoosePolSound-SoundType , TRightToChoosePo 
ISound-PhoneFuncionality , MessagesState , TMessage-MainDisplay-IncomingMess}. 

In accordance with the strategy defined in section [572] , must apply the rules in the following order: 

Delete _condition(MessagesSt ate, sc) — > Delete _simple_state(SelectPolSound ,sc) — > Delete _simple_state(To 
ChoosePolSound , sc) — > Delete _transition(T RightMultimedia-Type-SelectPolSound ,sc) — > Delete Jransition( 
T Right SoundType-ToChoosePolSound, sc) — > Delete Jransition(TLeftToChoosePolSound-SoundType, sc) — > 
Delete Jransition(TRightToChoosePolSound-PhoneFuncionality,sc) — > Delete J ransition(T Message-MainDis 
play-IncomingMess ,sc) — > Changing ^optional Jo j\onjoptional(sc). 

The resulting SC is observed in figure [5] 



6 Related Works 

A variety of existing approaches propose the incorporation of variability in software systems and in par- 
ticular on PLs. One of these is the one designed by Jacobson 031, whose weaknesses have been analyzed 
by several authors. Von der Maen [4] proposes the use of a graphical notation with new relations. John 
and Muthig lfl6l suggest the application of use case templates, although they do not distinguish between 
optional, alternative or obligatory variants. However, Halman and Pohl propose in ifTTl to make use of 
UML 2 package merge, based on (6J, as a tool for the variability representation and configuration in PLs. 
As opposed to the mentioned proposals, our solution is centered in one behavior specification model of 
a PL, as are the SCs, introducing a clearly defined formal sustenance. 

Also, to define PLs and to characterize their different products we use FMs, which admit a formal 
definition and allow us to configure the functional characteristics of a line. An alternative approach to this 
paper is developed in parallel by other members of the research project in which this work is subsumed. 
In (18 ] the authors, in a formal framework, define functions that associate SCs (not components of SCs, 
as in our case) to functionalities of a FM, and analyze forms of combination between different SCs 
which specify possible variants of a PL. Whereas under our method the behavior of a product into a 
PL is obtained basically by a selection process, in |[T8l the focus is oriented towards a process of SC 
combinations. 



54 



Specification of Products and Product Lines 




Figure 5: SC for a MP without polyphonic sounds and without alert of new messages. 

7 Conclusion and Further Work 

Most of the techniques of Model Driven Development make use of UML. In particular, the SCs of UML 
constitute a mechanism for specifying systems behavior by means of a graphical representation. In this 
work, we presented an extension of UML SCs by incorporating variability in their essential components 
to specify PLs. The variability is introduced in the SCs distinguishing optional and non-optional states as 
well as optional and non-optional transitions. A PL is specified with a SC*, a FM, and a formal relation 
(an implementation function) that binds both models. Using FMs to describe the common and variant 
functionalities and applying a rule-based instantiation method, concrete SCs corresponding to different 
PLs can be obtained. The approach defines the transformation strategy from extended SCs to standard 
UML SCs. We develop partial examples of a case study based on mobile phone technology, whose full 
version is not included in this article due to space restrictions. 

Given the fact that UML and SCs have become very successful languages for analysis and design in 
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the very short run, we are confident that the results of this work can be successfully applied to the real 
problems of the software industry. It is a timely contribution to an authentic and actual problem. 

As part of our plans for future work, we are interested in an extension of SCs which allows us to 
completely cover the UML 2.0 SCs and analyze variabilities, not only the ones considered in this paper, 
but in all of their components. Also, we will make an attempt to provide a formal semantics for the 
extension. This semantics is an essential preliminary step towards both the automatic code generation 
and the validation of complex software systems. 
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